6장. RAG와 에이전트

출처 — Chip Huyen, 『AI 엔지니어링』(한국어판), 6장 (pp. 305~363). 원문 PDF ai_engineering_final_v11_260909.pdf (2026-09-09 판)

모델은 지시만으로는 부족하다 — 컨텍스트를 어떻게 채우느냐가 응답의 품질을 가른다. RAG는 외부 지식을 검색해 컨텍스트를 채우고, 에이전트는 도구를 써서 그 이상을 한다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• RAG가 롱 컨텍스트로 대체될 수 없는 이유 두 가지를 설명한다.
• 희소 검색과 밀집 검색의 작동 원리와 트레이드오프를 비교한다.
• 청킹·재순위화·질의 재작성·컨텍스트 검색 중 상황에 맞는 검색 최적화 전략을 선택한다.
• 에이전트를 환경·행동·도구로 정의하고, 계획 생성·검증·실행·성찰의 순환 구조를 구현 수준에서 설명한다.
• 에이전트의 실패 유형(계획 수립 실패·도구 실패·비효율)을 구분하고 각각을 평가하는 지표를 설계한다.
• 내부 지식·단기 메모리·장기 메모리의 역할 차이를 근거로 정보를 어디에 저장할지 판단한다.

전체 흐름도

                              질의(query)
                                  │
                                  ▼
                  ┌───────────────────────────────┐
                  │   §1~4  RAG (검색 증강 생성)     │
                  │                                │
                  │  색인화 → 검색(희소/밀집/하이브리드)│
                  │   → 재순위화 → 컨텍스트 구성      │
                  │   → 생성 모델 응답                │
                  └───────────────┬───────────────┘
                                  │ 검색기는 에이전트가 쓰는
                                  │ "도구" 중 하나이기도 하다
                                  ▼
                  ┌───────────────────────────────┐
                  │   §5  에이전트                  │
                  │                                │
                  │  환경 인식 ─┐                    │
                  │            ▼                   │
                  │   계획 생성 → 계획 검증           │
                  │      │           │              │
                  │      │  (부적절)  │ (적절)        │
                  │      │←──────────┘              │
                  │      ▼                          │
                  │   실행(도구·함수 호출)            │
                  │      │                          │
                  │      ▼                          │
                  │   성찰 및 오류 수정 ──┐            │
                  │      │              │           │
                  │      │ (미완료)      │ (완료)      │
                  │      └──────────────┘           │
                  └───────────────┬───────────────┘
                                  │
                                  ▼
                  ┌───────────────────────────────┐
                  │   §6  메모리                     │
                  │  내부 지식 · 단기 메모리(컨텍스트) │
                  │  · 장기 메모리(외부 저장소)        │
                  │  — 컨텍스트 한계를 넘는 정보를 관리 │
                  └───────────────────────────────┘

0. 용어 사전

참고 — 위쪽 4개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 1장·2장·5장을 먼저 보라.

1. RAG란 무엇이고 왜 필요한가

RAG(검색 증강 생성)는 외부 메모리 소스에서 관련 정보를 검색해 모델의 생성을 향상시키는 기술이다. 외부 메모리 소스는 내부 데이터베이스, 사용자의 이전 채팅 세션, 인터넷 등 무엇이든 될 수 있다. 원형은 검색 후 생성(retrieve-then-generate) 패턴으로, Chen 등(2017)의 「Reading Wikipedia to Answer Open-Domain Questions」이 위키피디아 페이지를 검색해 모델이 읽고 응답하게 한 것이 시초다. "검색 증강 생성"이라는 이름 자체는 Lewis 등(2020)의 논문 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」에서 처음 쓰였다. 이 논문은 가용한 지식 전부를 모델에 직접 넣기 어려운 지식 집약적 작업을 풀기 위해 RAG를 제안했다 — 검색기가 질의와 가장 관련성 높다고 판단한 정보만 모델에 넣으면, 모델은 더 자세하면서도 환각이 적은 응답을 만든다.

왜 롱 컨텍스트로 대체되지 않는가. 파운데이션 모델이 처음 등장했을 때 RAG는 모델의 컨텍스트 제한을 극복하려는 목적이 컸다. 컨텍스트 길이가 계속 길어지면 RAG의 필요성이 사라질 것이라는 예상이 있지만, 저자는 두 가지 이유로 반박한다. 첫째, 데이터 양은 시간이 지나며 계속 늘어난다(사람은 새 데이터를 만들지만 거의 지우지 않는다) — 컨텍스트가 아무리 길어져도 그보다 더 긴 데이터가 필요한 애플리케이션이 항상 나타난다. 둘째, 컨텍스트가 길다고 모델이 그것을 잘 활용하는 것은 아니다(5장 §컨텍스트 길이와 정보 배치에서 다룬 문제) — 컨텍스트가 길수록 모델이 엉뚱한 부분에 집중할 위험이 커지고, 토큰이 늘수록 비용과 지연도 늘어난다. RAG는 각 질의에 가장 관련성 높은 정보만 사용하게 해 입력 토큰을 줄이면서도 성능을 높인다.

참고 — 앤트로픽은 지식 베이스가 20만 토큰(약 500쪽) 미만이면 RAG 없이 전체를 프롬프트에 넣어도 된다고 조언한 바 있다(2024). 즉 RAG는 항상 필요한 것이 아니라, 지식 베이스가 컨텍스트에 다 안 들어갈 때의 해법이다.

두 구성 요소. RAG 시스템은 검색기(외부 메모리에서 정보를 찾는 부분)와 생성 모델(검색된 정보로 응답을 만드는 부분)로 이루어진다. 원래 논문에서는 두 요소를 함께 학습시켰지만, 오늘날은 이미 만들어진 검색기와 생성 모델을 조합해 쓰는 경우가 많다(전체를 처음부터 파인튜닝하면 성능이 더 좋아질 수는 있다). 검색기의 두 핵심 기능은 색인화(나중에 빠르게 찾도록 데이터를 미리 처리)와 질의(관련 데이터를 찾기 위한 요청)다 — 데이터를 어떻게 색인화할지는 나중에 어떻게 검색하고 싶은지에 달려 있다.

작동 예시. 외부 메모리가 회사의 메모·계약서·회의록 같은 문서 데이터베이스라고 하자. 문서 전체를 그대로 검색하면 컨텍스트가 지나치게 길어지므로, 각 문서를 관리하기 쉬운 청크로 나눈다(청킹 전략은 §3에서 다룬다). 질의가 들어오면 가장 관련성 높은 청크를 찾고, 이를 사용자 프롬프트와 합쳐(약간의 후처리를 거쳐) 최종 프롬프트를 만들어 생성 모델에 넣는다. 이 장에서는 문서와 청크를 모두 "문서"라고 부른다 — 청크도 결국 하나의 문서로 볼 수 있고, 전통적인 정보 검색(IR) 분야의 용어와도 맞기 때문이다.

2. 검색 알고리즘

검색은 RAG와 함께 등장한 개념이 아니다. 정보 검색은 100년이 넘은 분야로, 검색 엔진·추천 시스템·로그 분석의 근간이며, 그간 개발된 여러 검색 알고리즘이 RAG에도 그대로 쓰인다. 핵심적으로 검색은 질의에 대한 문서들의 관련성을 기준으로 순위를 매기는 방식으로 작동하며, 관련성 점수를 계산하는 방법에 따라 알고리즘이 갈린다. 이 장은 일반적으로 쓰이는 희소·밀집(원서는 용어 기반·임베딩 기반이라는 분류를 택했다) 두 계열을 다룬다.

희소 검색(용어 기반 검색)

희소 검색기는 데이터를 희소 벡터(값 대부분이 0인 벡터)로 표현한다. 각 용어가 원-핫 벡터로 표현되기 때문이다. 예를 들어 사전이 {"food": 0, "banana": 1, "slug": 2}라면 각 단어의 원-핫 벡터는 [1,0,0], [0,1,0], [0,0,1]이다. 가장 단순한 방법은 키워드 일치로, "AI 엔지니어링"을 검색하면 그 문구를 포함하는 문서를 모두 가져온다. 문제는 두 가지다.

첫째, 원하는 용어가 너무 많은 문서에 나타날 수 있다. 해결책은 그 용어가 자주 등장하는 문서를 우선하는 것이다 — 용어가 문서에 등장하는 횟수를 용어 빈도(term frequency, TF)라 한다. 둘째, 모든 용어가 똑같이 중요하지 않다("집에서 쉽게 만들 수 있는 베트남 음식 레시피"에서 '베트남'·'레시피'는 핵심이지만 '수'·'있는'은 아니다). 많은 문서에 흔히 등장하는 용어일수록 정보량이 적다는 직관을 담은 지표가 역문서 빈도(inverse document frequency, IDF)다 — 전체 문서 수를 그 용어가 포함된 문서 수로 나눈 값이며(총 10개 문서 중 5개에 있으면 IDF=10/5=2), 값이 클수록 그 용어가 중요하다.

TF-IDF는 이 둘을 결합한다. 질의 $Q$의 용어를 $t_1, \ldots, t_n$이라 하고, 문서 $D$에서 용어 $t$의 빈도를 $f(t, D)$, 전체 문서 수를 $N$, $t$를 포함하는 문서 수를 $C(t)$라 하면 $\mathrm{IDF}(t) = \log \frac{N}{C(t)}$이고, 질의 $Q$에 대한 문서 $D$의 점수는 다음과 같다.

Score(D, Q) = Σ_{i=1}^{n} IDF(t_i) × f(t_i, D)

자주 쓰이는 두 솔루션은 엘라스틱서치(Elasticsearch, 2010)와 BM25다. 엘라스틱서치는 루씬(Lucene) 기반으로 역색인(용어를 문서로 매핑하는 사전) 구조를 활용해 용어가 주어지면 관련 문서를 빠르게 찾고, 용어 빈도·문서 수 같은 부가 정보도 함께 저장해 TF-IDF 계산에 쓴다. 오카피 BM25(Okapi BM25, 1980년대 로버트슨 등이 개발한 베스트 매칭 알고리즘의 25번째 세대)는 TF-IDF를 개선한 것으로, 문서 길이를 고려해 용어 빈도 점수를 정규화한다 — 긴 문서일수록 특정 용어가 등장할 확률이 자연히 높아지기 때문이다. BM25와 그 변형(BM25+, BM25F)은 지금도 산업계에서 널리 쓰이며, 더 정교한 임베딩 기반 검색과 비교할 때 중요한 기준점 역할을 한다.

토큰화의 함정. 질의를 단어 단위로 쪼개면 '핫도그'가 '핫'과 '도그'로 갈라져 본래 의미를 잃는다 — 자주 함께 등장하는 n-gram(예: bigram '핫도그')을 하나의 용어로 묶는 것이 한 해법이다. 소문자화·구두점 제거·불용어 제거는 NLTK·spaCy·CoreNLP 같은 전통 NLP 도구가 자동으로 처리해 준다. n-gram 중복으로 문서를 검색할 수도 있지만, 문서가 질의보다 훨씬 길면 여러 문서가 비슷하게 높은 중복 점수를 받아 변별력이 떨어진다.

밀집 검색(임베딩 기반 검색)

용어 기반 검색은 단어의 형태만 보고 의미는 보지 못한다 — '트랜스포머 아키텍처'를 검색하면 AI 모델이 아니라 전기 장치나 영화에 관한 문서가 나올 수 있다. 밀집 검색기는 문서의 의미가 질의와 얼마나 가까운지로 순위를 매기며(의미 기반 검색이라고도 한다), 값 대부분이 0이 아닌 밀집 벡터로 데이터를 표현한다. 임베딩 기반 검색의 색인화는 원본 청크를 임베딩으로 바꾸는 일이 하나 더 있고, 그 결과를 저장하는 곳이 벡터 데이터베이스다. 질의 과정은 두 단계다 — ① 색인화에 쓴 것과 같은 임베딩 모델로 질의를 임베딩으로 바꾸고, ② 검색기가 질의 임베딩과 가장 가까운 $k$개의 청크를 가져온다. 임베딩 모델이 부실하면 밀집 검색도 당연히 부실해진다(3장 §임베딩 소개의 평가 논의가 여기서 다시 쓰인다).

참고 — 희소·밀집 분류를 따르면 SPLADE(Formal et al., 2021, BERT 임베딩을 정규화해 대부분을 0으로 만드는 희소 임베딩)가 용어 기반과 같은 범주로 묶이는데, 실제 작동 방식은 밀집 임베딩 검색에 훨씬 가깝다. 원서가 "희소/밀집" 대신 "용어 기반/임베딩 기반" 분류를 택한 이유가 이것이다.

밀집 검색은 보통 최근접 이웃 검색 문제로 접근한다. 가장 기본적인 k-NN(k-최근접 이웃) 알고리즘은 ① 질의 임베딩과 모든 벡터 간 유사도(코사인 유사도 등)를 계산 → ② 유사도로 순위를 매김 → ③ 상위 $k$개를 반환한다. 결과가 정확하다는 것은 보장하지만 계산량이 많아 작은 데이터셋에만 쓸 수 있다. 그래서 큰 데이터셋에는 근사 최근접 이웃(ANN) 알고리즘을 쓴다. 대표적인 라이브러리로 FAISS(Johnson et al., 2017), 구글 ScaNN(Sun et al., 2020), 스포티파이 Annoy(Bernhardsson, 2013), HNSW 구현체 Hnswlib(Malkov and Yashunin, 2016) 등이 있다.

벡터 데이터베이스는 보통 벡터를 버킷·트리·그래프로 구성하고, 정밀도를 낮추거나(양자화) 희소하게 만들어 연산 자원을 아낀다. 대표적인 ANN 알고리즘은 다음과 같다.

• 지역 민감 해싱(LSH)(Indyk and Motwani, 1999) — 유사한 벡터를 같은 버킷에 해싱해 정확도를 일부 희생하는 대신 속도를 얻는다. FAISS·Annoy에 구현돼 있다.
• HNSW(Malkov and Yashunin, 2016) — 노드가 벡터, 엣지가 유사도를 나타내는 다중 레이어 그래프를 만들고, 검색 시 이 그래프를 따라 이동한다. FAISS·Milvus에 구현돼 있다.
• 제품 양자화(Jégou et al., 2011) — 벡터를 여러 하위 벡터로 분해해 저차원으로 표현, 거리 계산을 빠르게 한다. FAISS의 핵심 구성 요소다.
• 역파일 색인(IVF)(Sivic and Zisserman, 2003) — K-평균 클러스터링으로 유사한 벡터를 같은 클러스터로 묶고, 질의가 오면 가장 가까운 클러스터의 벡터만 후보로 본다. 제품 양자화와 함께 FAISS의 근간을 이룬다.
• Annoy(Bernhardsson, 2013) — 무작위 선을 기준으로 벡터를 반복해서 두 그룹으로 나누는 트리 기반 접근이다.

일반적으로 HNSW처럼 상세한 색인은 정확도와 질의 속도가 높지만 구축에 시간과 메모리가 많이 들고, LSH처럼 단순한 색인은 빠르게 만들 수 있지만 질의 속도와 정확도가 떨어진다. ANN-벤치마크는 재현율·초당 질의 수(QPS)·구축 시간·색인 크기 네 지표로 여러 데이터셋에서 알고리즘을 비교하며, BEIR(Thakur et al., 2021)는 14개 검색 벤치마크를 지원하는 평가 도구다.

검색 품질 평가와 비교

검색기의 품질은 검색되는 데이터의 품질로 평가한다. 가장 많이 쓰이는 두 지표는 다음과 같다.

• 컨텍스트 정밀도(context precision, 컨텍스트 관련성) — 검색된 모든 문서 중 실제로 질의와 관련된 문서의 비율.
• 컨텍스트 재현율(context recall) — 질의와 관련된 모든 문서 중 실제로 검색된 문서의 비율.

컨텍스트 재현율은 데이터베이스의 모든 문서와 질의의 관련성을 다 주석 달아야 해서 계산이 무겁고, 그래서 운영 환경에서는 컨텍스트 정밀도만 지원하는 RAG 프레임워크가 많다(정밀도는 검색된 문서만 보면 되므로 AI 평가자로도 계산할 수 있다). 순위가 중요할 때는 NDCG·MAP·MRR 같은 지표를 쓴다. 의미 기반 검색에서는 임베딩 자체의 품질(비슷한 문서가 벡터 공간에서 가까운가)과 특정 작업 성능(MTEB 벤치마크, Muennighoff et al., 2023)도 함께 평가해야 한다. 최종적으로는 생성 모델의 출력까지 포함한 전체 RAG 시스템 성능(3장 §AI 평가자·4장 §생성 능력 — 사실 일관성에서 다룬 평가 방법)으로도 검증해야 한다.

용어 기반 vs 임베딩 기반: 용어 기반 검색은 색인화·질의 모두 임베딩 기반보다 훨씬 빠르고 설정 없이도 잘 작동하지만, 조정할 구성 요소가 적다. 임베딩 기반 검색은 파인튜닝으로 시간이 지나며 크게 개선될 수 있지만, 데이터를 임베딩으로 바꾸면 EADDRNOTAVAIL(99) 같은 특정 오류 코드나 제품명 같은 키워드가 희석돼 검색이 어려워질 수 있다(하이브리드 검색으로 보완한다). 비용 측면에서도 벡터 데이터베이스 비용이 모델 API 비용의 5분의 1에서 절반에 이르는 경우가 흔하다.

검색 알고리즘 결합하기(하이브리드 검색). 운영 환경의 검색 시스템은 보통 여러 접근을 결합한다. ① 순차 결합: 비용이 적고 정확도가 낮은 검색기(예: 용어 기반)로 후보를 추리고, 더 정확하지만 비용이 큰 방식(예: k-NN)으로 재순위화한다. 예를 들어 '트랜스포머'를 키워드로 모든 문서를 가져온 뒤 벡터 검색으로 실제 관련 문서를 추린다. ② 앙상블(역순위 퓨전, RRF)(Cormack et al., 2009): 여러 검색기의 순위를 하나로 합친다. 1위 문서 점수는 $1/1=1$, 2위는 $1/2=0.5$이고, 한 문서가 검색기 A에서 1위·검색기 B에서 2위라면 최종 점수는 $1+0.5=1.5$다. 문서 $D$에 대한 일반식은 다음과 같다.

Score(D) = Σ_{i=1}^{n} 1 / (k + r_i(D))

여기서 $n$은 순위 목록(검색기)의 수, $r_i(D)$는 검색기 $i$가 매긴 문서 $D$의 순위, $k$는 0으로 나누는 것을 막고 낮은 순위 문서의 영향을 줄이는 상수(흔히 60)다.

3. 검색 최적화

관련 문서가 검색될 가능성을 높이는 전략은 크게 네 가지다 — 청킹 전략, 재순위화, 질의 재작성, 컨텍스트 검색.

청킹 전략

문서를 어떻게 색인화할지는 어떻게 검색할지에 달려 있다. 가장 단순한 전략은 문자·단어·문장·단락 같은 고정 단위로 동일한 길이의 청크를 만드는 것이다(예: 2,048자 또는 512단어). 재귀적 분할(절 → 단락 → 문장 순으로 점점 작은 단위를 시도)은 관련 내용이 임의로 끊길 가능성을 줄인다. 코드처럼 특정 문서 유형은 언어별 분할기를, Q&A 문서는 질문-응답 쌍 단위를, 중국어처럼 문장 구분이 다른 언어는 별도 규칙을 쓴다.

청크를 겹침 없이 나누면 경계에서 중요한 정보가 끊길 수 있다("I left my wife a note"가 "I left my wife"와 "a note"로 갈리면 둘 다 원래 의미를 잃는다). 청크 간 겹침은 중요한 경계 정보가 최소 한 청크에는 포함되도록 보장한다(예: 청크 2,048자에 겹침 20자). 청크 크기는 생성 모델·임베딩 모델의 최대 컨텍스트를 넘지 않아야 하며, 생성 모델의 토크나이저 경계로 청킹할 수도 있으나 이 경우 생성 모델을 바꾸면 전체를 다시 색인화해야 하는 단점이 있다.

크기의 트레이드오프. 청크가 작을수록 같은 컨텍스트 예산으로 더 다양한 청크를 담을 수 있어 응답 품질에 도움이 되지만, 정보가 청크 경계에서 끊겨 손실될 수 있고(문서 앞부분에만 나온 키워드 때문에 뒷부분이 통째로 안 찾아질 수 있다), 색인화할 청크와 임베딩 수가 늘어 계산·저장 부담도 커진다. 모든 상황에 맞는 하나의 청크 크기·겹침 크기는 없으며, 실험으로 찾아야 한다.

재순위화

검색기가 만든 초기 순위는 더 정확하게 다시 매길 수 있다. 재순위화는 모델 컨텍스트에 맞추거나 입력 토큰을 줄이기 위해 검색된 문서 수를 줄여야 할 때 특히 유용하며, 일반적인 패턴은 §2의 하이브리드 검색(순차 결합)과 같다 — 저렴하고 부정확한 검색기가 후보를 추리고, 정확하지만 비용이 큰 메커니즘이 재순위화한다. 문서는 시간을 기준으로도 재순위될 수 있다(뉴스·이메일·주식 분석처럼 시간에 민감한 애플리케이션에 유용). 컨텍스트 재순위화는 전통적인 검색 재순위화와 달리 정확한 위치보다 "포함 여부"가 더 중요하다 — 모델이 컨텍스트의 시작과 끝을 더 잘 이해하는 경향은 있지만(5장 §컨텍스트 길이와 정보 배치), 순서의 영향은 검색 순위 자체보다는 작다.

질의 재작성

질의 재구성·정규화·확장이라고도 한다. 다음 대화를 보자.

사용자: 존 도가 마지막으로 우리에게서 무언가를 구매한 것은 언제인가요?
AI: 존은 2030년 1월 3일, 2주 전에 마지막으로 과일 모자를 구매했습니다.
사용자: 에밀리 도는 어떤가요?

마지막 질의 "에밀리 도는 어떤가요?"는 맥락 없이는 모호해서, 그대로 검색하면 관련 없는 결과가 나오기 쉽다. 사용자 의도를 반영해 "에밀리 도가 마지막으로 우리에게서 무언가를 구매한 것은 언제인가요?"로 재작성해야 새 컨텍스트 없이도 의미가 분명해진다. 재작성은 휴리스틱으로도, 다른 AI 모델에 "다음 대화를 고려할 때 사용자가 실제로 묻는 내용을 반영해 마지막 입력을 재작성하라"는 프롬프트를 줘서도 할 수 있다. 신원 확인이 필요한 경우("그의 아내는 어떤가요?")는 더 복잡해진다 — 답을 모르면 재작성 모델이 이름을 지어내기보다 "답을 찾을 수 없다"고 알려야 한다.

컨텍스트 검색

각 청크에 관련 컨텍스트를 덧붙여 검색이 쉬워지게 하는 기법이다. 가장 간단한 방법은 태그·키워드 같은 메타데이터로 청크를 보강하는 것이다(전자상거래라면 상품 설명·리뷰를 함께 저장, 이미지·동영상은 제목·캡션으로 검색). 자동 추출된 개체도 메타데이터가 될 수 있다 — 문서에 EADDRNOTAVAIL(99) 같은 오류 코드가 있으면 메타데이터로 남겨 두면 임베딩으로 바뀐 뒤에도 그 키워드로 찾을 수 있다. 각 청크에 그 청크가 답할 수 있는 질의들을 미리 붙여 둘 수도 있다(비밀번호 재설정 문서에 "비밀번호를 어떻게 재설정하나요?" 같은 질의를 매달아 두는 식).

문서가 여러 청크로 나뉘면 일부 청크는 내용을 이해할 컨텍스트가 부족해질 수 있다. 앤트로픽은 이를 해결하기 위해 AI 모델로 청크와 원본 문서의 관계를 설명하는 짧은 컨텍스트(보통 50~100토큰)를 생성해 각 청크 앞에 붙이는 컨텍스트 검색(Contextual Retrieval)을 공개했다(Anthropic, 2024). 생성된 컨텍스트가 앞에 붙은 보강 청크는 그대로 검색 알고리즘에 색인화된다.

참고 — 검색 솔루션을 고를 때 볼 것. 어떤 검색 방식(하이브리드 포함)을 지원하는가, 어떤 임베딩 모델·벡터 검색 알고리즘을 지원하는가, 저장량·트래픽 대비 확장성은 어떤가, 색인화·대량 처리 속도는 어떤가, 질의 지연 시간은 어떤가, 관리형이라면 가격 체계(저장량 기준인지 요청 수 기준인지)는 어떤가. 접근 권한 관리·법규 준수 같은 일반적인 기업용 기능은 이 목록에 포함되지 않는다.

4. 텍스트를 넘어선 RAG

지금까지는 외부 데이터 소스가 텍스트인 경우만 봤다. 실제로는 멀티모달 데이터나 표 형식 데이터도 흔하다.

멀티모달 RAG

생성 모델이 멀티모달 데이터를 처리할 수 있다면 컨텍스트는 텍스트뿐 아니라 이미지·비디오·오디오도 활용할 수 있다. 예를 들어 "픽사 영화 <업>에 나오는 집의 색깔은?"이라는 질의에는 검색기가 관련 이미지를 찾아올 수 있다. 이미지에 제목·태그·캡션 메타데이터가 있으면 그것으로 검색하면 되지만, 이미지 내용 자체로 검색하려면 이미지와 텍스트를 같은 벡터 공간으로 보내는 멀티모달 임베딩 모델이 필요하다. CLIP(Radford et al., 2021)을 예로 들면 과정은 ① 텍스트·이미지 모두의 CLIP 임베딩을 만들어 벡터 데이터베이스에 저장, ② 질의의 CLIP 임베딩을 만듦, ③ 벡터 데이터베이스에서 질의 임베딩과 가장 유사한 이미지·텍스트를 찾는 것이다.

표 형식 데이터를 활용한 RAG(Text-to-SQL)

많은 질의는 표에 담긴 정보가 필요하다. 가상의 전자상거래 사이트 "키티 보그"(Kitty Vogue)의 주문 테이블 Sales를 예로 들어보자. "지난 7일 동안 과일 페도라가 몇 개 팔렸나요?"라는 질의에 답하려면 시스템이 관련 주문을 질의해 판매 수량을 합산해야 한다.

참고 — 원문이 완벽하지 않을 때. 원문의 Sales 테이블 예시(표 6-3)는 PDF 추출 과정에서 열과 값이 뒤섞였다(주문 ID·타임스탬프·제품 ID·단가·단위·합계가 뒤섞인 숫자열로 나열됨). 이 표는 추출 손상으로 옮기지 않는다 — 뒤섞인 숫자를 그럴듯하게 재배열하면 추측이 사실처럼 보이게 된다. 다만 이어지는 SQL 예시는 추출이 온전해 그대로 옮긴다.

SELECT SUM(units) AS total_units_sold
FROM Sales
WHERE product_name = 'Fruity Fedora'
  AND timestamp >= DATE_SUB(CURDATE(), INTERVAL 7 DAY);

잘못된 예 — 이 흐름을 사람이 매번 SQL을 직접 짜서 실행한다면, 사용자 질의마다 개발자가 개입해야 해서 자동화가 안 된다. 올바른 예 — 시스템이 다음 세 단계를 자동 수행한다.

1. Text-to-SQL — 사용자 질의와 테이블 스키마를 보고 어떤 SQL이 필요한지 결정한다(2장 §샘플링에서 다룬 시맨틱 파싱의 한 예다). 사용 가능한 테이블이 너무 많으면 어떤 테이블을 쓸지 먼저 예측하는 중간 단계가 필요할 수 있고, 최종 응답 생성과 같은 모델을 쓸 수도, 전용 모델을 쓸 수도 있다.
2. SQL 실행 — 만들어진 쿼리를 실행한다.
3. 응답 생성 — 실행 결과와 사용자 질의를 토대로 응답을 만든다.

이 절에서 검색기와 SQL 실행기 같은 도구가 모델의 질의 처리 능력을 넓히는 것을 봤다. 모델에 더 많은 도구를 주면 능력이 더 커질까? 도구 사용은 다음 절 에이전트 패턴의 핵심이다.

5. 에이전트

5.1 에이전트란 무엇인가

많은 사람이 AI의 궁극적 목표로 여기는 것이 지능형 에이전트다. 러셀과 노빅의 고전 「Artificial Intelligence: A Modern Approach」(1995)는 AI 연구를 "합리적 에이전트의 연구와 설계"로 정의했다.

참고 — 이 절은 아직 확립된 이론적 프레임워크가 없는 신생 분야를 다루므로, 책의 다른 부분보다 실험적인 성격이 강하다.

정의. 에이전트는 자신의 환경을 인식하고 그 환경에서 행동할 수 있는 모든 것이다 — 즉 작동하는 환경과 수행할 수 있는 행동으로 정의된다. 환경은 활용 사례에 따라 정해진다(게임 에이전트라면 게임이, 인터넷 문서 수집 에이전트라면 인터넷이, 요리 로봇이라면 주방이, 자율주행차라면 도로 시스템이 환경이다). AI 에이전트가 할 수 있는 행동은 접근할 수 있는 도구로 확장된다 — 우리가 일상적으로 쓰는 생성형 AI 앱(웹 검색·코드 실행·이미지 생성이 되는 챗봇)도 단순하지만 도구를 쓰는 에이전트이고, RAG 시스템도 텍스트 검색기·이미지 검색기·SQL 실행기라는 도구를 쓰는 에이전트다.

환경과 도구 사이에는 강한 의존성이 있다 — 환경은 에이전트가 쓸 수 있는 도구를 정하고(체스 게임이면 체스 규칙이 허용하는 수만 가능), 반대로 도구 목록은 활동할 수 있는 환경을 제한한다(수영만 하는 로봇은 물 환경에서만 움직인다). SWE-agent(Yang et al., 2024)는 GPT-4 위에 구축돼 터미널과 파일 시스템이 있는 컴퓨터를 환경으로 삼고, 저장소 탐색·파일 검색·파일 보기·줄 편집을 행동으로 갖는다.

AI 에이전트에서 AI는 작업과 환경 피드백을 처리하는 두뇌 역할을 하며, 행동 순서를 계획하고 작업 완료 여부를 판단한다. §4의 키티 보그 예시로 돌아가면, "향후 3개월간 과일 페도라 판매 수익을 예측해 달라"는 질의에 에이전트는 다음처럼 행동할 수 있다 — ① 예측에 지난 5년 매출이 필요하다고 추론(중간 응답) → ② SQL 생성 도구 호출 → ③ SQL 실행 도구 호출 → ④ 값이 누락돼 마케팅 캠페인 정보도 필요하다고 추론 → ⑤~⑥ 다시 SQL 생성·실행 → ⑦ 충분하다고 판단, 예측치 생성 → ⑧ 작업 완료로 판단.

왜 더 강력한 모델이 필요한가. 두 가지 이유다. ① 누적 오류 — 단계가 늘수록 전체 정확도는 떨어진다(단계당 정확도 95%면 10단계 후 60%, 100단계 후 0.6%). ② 더 큰 위험 — 도구를 쓸 수 있게 되면서 더 영향력 있는 작업을 하지만, 실패하면 결과도 더 심각해진다. 단계가 많은 작업은 시간·비용이 들지만, 자율적으로 작동하면 사람의 시간을 크게 아낄 수 있어 감수할 만하다.

5.2 도구

시스템이 에이전트가 되기 위해 외부 도구가 꼭 필요하지는 않지만, 도구 없이는 능력이 제한적이다. 모델 자체는 보통 한 가지 행동만 한다(LLM은 텍스트 생성, 이미지 생성기는 이미지 생성). 도구는 에이전트에게 환경을 인식하는 능력(읽기)과 환경을 바꾸는 능력(쓰기)을 준다. 도구 목록은 에이전트가 할 수 있는 일을 결정하므로 신중히 골라야 한다 — 도구가 많을수록 능력은 커지지만 이해·활용은 어려워진다.

지식 증강. 텍스트 검색기·이미지 검색기·SQL 실행기 외에도 내부 인물 검색, 재고 API, 슬랙 메시지 검색, 이메일 읽기 도구 등이 있다. 도구는 조직 내부 정보뿐 아니라 인터넷 같은 공개 정보에도 접근하게 해 준다. 웹 브라우징(검색 API·뉴스 API·깃허브 API·소셜 미디어 API를 포괄)은 모델이 학습 데이터 마감 이후의 최신 정보(날씨·뉴스·주가·항공편 등)에 답하게 해 주지만, 유해 콘텐츠 노출 위험도 있어 신중히 골라야 한다.

능력 확장. AI 모델은 기본적으로 산술에 약하다(199,999를 292로 나눈 값을 물으면 실패하기 쉽다) — 계산기 도구를 주는 편이 산술 능력을 학습시키는 것보다 훨씬 효율적이다. 캘린더·시간대 변환기·단위 변환기·번역기도 같은 역할을 한다. 더 강력한 도구는 코드 인터프리터다 — 모델이 코드를 실행·분석하게 해 코딩 도우미·데이터 분석가·연구 조수 역할을 가능하게 하지만, 자동 코드 실행에는 코드 주입 공격 위험이 따르므로(5장 §프롬프트 공격에 대한 방어) 보안 조치가 필수다. 외부 도구는 텍스트/이미지 전용 모델을 멀티모달로 만들 수도 있다(텍스트-이미지 변환 모델을 도구로 쓰면 챗봇이 이미지도 생성할 수 있다). 카멜레온(Chameleon, Lu et al., 2023)은 13개 도구로 보강된 GPT-4 기반 에이전트가 여러 벤치마크에서 GPT-4 단독보다 성능이 좋았음을 보였다(ScienceQA에서 기존 최고 퓨샷 대비 11.37% 향상, TabMWP에서 정확도 17% 향상).

쓰기 행동. 도구는 데이터 소스를 바꾸는 쓰기 행동도 한다 — SQL 실행기는 테이블을 변경·삭제할 수 있고, 이메일 API는 답장을 보낼 수 있고, 은행 API는 송금을 시작할 수 있다. 쓰기 행동은 잠재 고객 조사부터 이메일 발송, 주문 정보 업데이트까지 자동화할 수 있게 하지만, 신뢰할 수 없는 AI에 은행 송금 권한을 주는 것과 같은 위험이 따른다(인턴에게 운영 데이터베이스 삭제 권한을 주지 않는 것과 같다). 시스템의 능력만큼 보안에 대한 신뢰도 중요하며, 악의적 사용자의 조작에도 견뎌야 한다.

함수 호출. 도구가 곧 함수이므로 도구 사용을 함수 호출(function calling)이라고도 한다. 일반적인 작동은 ① 도구 목록 생성(실행 진입점·파라미터·문서로 구성) → ② 질의별 사용할 도구 지정(required=반드시 하나 이상 사용, none=사용 안 함, auto=모델이 결정)이다.

실무 예제 — 함수 호출 응답의 구조와 검토. "40파운드는 몇 킬로그램인가요?"라는 질의에 에이전트가 lbs_to_kg 도구와 파라미터 40이 필요하다고 판단하면 응답은 다음과 같은 형태다(원문 그림 6-10을 코드로 옮김).

response = ModelResponse(
    finish_reason='tool_calls',
    message=chat.Message(
        content=None,
        role='assistant',
        tool_calls=[
            ToolCall(
                function=Function(
                    arguments='{"lbs": 40}',
                    name='lbs_to_kg'),
                type='function')
        ]
    )
)

잘못된 예 — 이 응답을 받자마자 파라미터 값을 검토하지 않고 바로 lbs_to_kg(lbs=40)을 실행한다. 올바른 예 — 함수 호출 API는 유효한 함수 이름은 보장해도 파라미터 값이 올바른지는 보장하지 않으므로, 실행 전에 시스템이 각 호출의 파라미터 값을 사람이 확인할 수 있게 노출한다(원문 TIP). 값 검증을 건너뛰면 유효한 도구를 잘못된 값으로 호출하는 실패(§5.4)로 이어진다.

5.3 계획 수립

파운데이션 모델 에이전트의 핵심에는 작업을 해결하는 모델이 있다. 작업은 목표와 제약 조건으로 정의된다(예: "5,000달러 예산으로 샌프란시스코~인도 2주 여행 계획" — 2주 여행이 목표, 예산이 제약). 계획은 작업 완수에 필요한 단계를 정리한 로드맵이고, 계획을 만드는 과정이 계획 수립이다. 같은 작업도 여러 방식으로 풀 수 있지만 효율은 다르다 — "수익 없이 최소 10억 달러를 조달한 회사는 몇 개인가?"라는 질의에서 ① 수익 없는 회사를 먼저 찾고 조달액으로 거르는 방법보다 ② 10억 달러 조달 회사를 먼저 찾고 수익으로 거르는 방법이 더 효율적이다(후자가 다뤄야 할 후보 수가 훨씬 적기 때문).

계획과 실행의 분리. 계획 수립과 실행을 한 프롬프트에서 결합할 수도 있지만, 모델이 목표를 이루지도 못하는 1,000단계 계획을 세우면 감독 없이 시간과 비용만 낭비된다. 그래서 먼저 계획을 만들게 하고, 검증된 후에만 실행한다. 계획은 휴리스틱으로(예: 유효하지 않은 행동이 포함된 계획 제거, X단계보다 긴 계획 제거) 또는 AI 평가자로 검증할 수 있다. 계획이 부적절하면 재생성을, 괜찮으면 실행에 들어간다(도구 사용이 있다면 함수 호출 수행). 실행 결과도 다시 평가를 거친다 — 이때 생성된 계획이 전체 작업의 모든 단계를 담을 필요는 없고, 작은 하위 작업의 계획일 수도 있다. 계획 생성·검증·실행이라는 세 구성 요소를 각각 에이전트로 보면 멀티 에이전트 시스템이 된다. 지연 시간을 줄이려면 계획을 순서대로 만드는 대신 여러 계획을 동시에 만들고 평가자가 최적을 고르게 할 수도 있다(추가 비용과의 트레이드오프). 계획 수립은 작업 뒤의 의도를 이해해야 하므로 의도 분류기가 자주 함께 쓰인다 — 의도 분류기는 에이전트가 처리할 수 없는 요청을 "관련 없음"으로 분류해 계산 자원 낭비를 막아야 한다. 위험한 작업(데이터베이스 업데이트, 코드 변경 병합)은 실행 전 사람의 명시적 승인을 요구하도록 자동화 수준을 정의할 수 있다.

정리하면 작업 해결은 보통 다음 순서다(성찰은 필수는 아니지만 성능을 크게 높인다).

1. 계획 생성 — 작업을 관리 가능한 행동들로 분해한다("단계별로 생각해봐"가 이에 해당한다).
2. 성찰과 오류 수정 — 계획을 평가하고, 좋지 않으면 새로 만든다("응답이 맞는지 확인해봐"가 이에 해당한다).
3. 실행 — 계획대로 행동한다(주로 함수 호출).
4. 성찰과 오류 수정 — 결과와 목표 달성 여부를 평가하고, 오류가 있으면 고치거나 새 계획을 세운다.

파운데이션 모델이 계획을 세울 수 있는가. 아직 명확하지 않다. 얀 르쿤(Yann LeCun, 2023)은 자기회귀 LLM이 계획을 세울 수 없다고 단언했고, 캄바함파티(Kambhampati, 2023)는 LLM이 지식 추출에는 뛰어나지만 계획 수립에는 그렇지 않다며, "일반적인 계획 지식"과 "실제로 실행 가능한 계획"을 혼동하는 연구가 많다고 지적했다. 계획 수립은 본질적으로 탐색 문제다 — 여러 경로를 탐색하고 각 결과를 예측해 가장 유망한 경로를 고르는 과정이며, 종종 백트래킹(되돌아가기)이 필요하다. 자기회귀 모델이 앞으로만 나아가 되돌아갈 수 없다는 주장도 있지만, 실제로는 실행 후 경로가 적절하지 않다고 판단하면 다른 경로로 수정할 수 있어 사실상 백트래킹과 같은 효과를 낼 수 있다. 또 다른 원인은 도구 부족일 수 있다 — 효과적인 계획에는 가능한 행동뿐 아니라 각 행동의 결과 상태도 알아야 하는데(등산 중 오른쪽으로 돌면 절벽이라는 정보가 있어야 그 행동을 배제할 수 있다), 단순히 행동 순서만 생성하는 CoT 프롬프팅은 이를 보장하지 않는다. 「Reasoning with Language Model is Planning with World Model」(Hao et al., 2023)은 LLM이 세계에 대한 방대한 정보를 담고 있어 각 행동의 결과를 예측할 수 있다고 주장한다. 완벽하게 계획을 세우지 못하더라도 검색 도구·상태 추적 시스템과 결합해 계획 수립 시스템의 일부로 쓰일 수 있다.

참고 — 파운데이션 모델(FM) 대 강화 학습(RL) 계획 수립자. 둘 다 환경과 가능한 행동에 따라 특성이 정해지지만, 계획을 세우는 방식이 다르다. RL 에이전트는 강화 학습 알고리즘으로 계획 능력을 학습하며 시간·자원이 많이 든다. FM 에이전트는 모델 자체가 계획 수립자 역할을 하며, 프롬프트나 파인튜닝으로 더 적은 자원으로도 계획 능력을 향상시킬 수 있다. FM 에이전트도 성능 향상에 RL을 활용할 수 있어, 장기적으로는 둘이 하나로 통합될 것으로 전망된다.

계획 생성 예시. 키티 보그의 고객 응대 에이전트에 가격별 제품 검색·인기 제품 검색·제품 정보 검색 세 도구를 준다고 하자. 시스템 프롬프트에 도구 목록과 예시(작업→계획 쌍)를 주면, "지난주 가장 잘 팔린 제품의 가격은 얼마인가요?"라는 질의에 다음과 같은 계획이 나올 수 있다.

1. get_time()
2. fetch_top_products()
3. fetch_product_info()
4. generate_query()
5. generate_response()

여기서 generate_query는 지금까지의 작업 기록과 가장 최근 도구 출력을 받아 응답 생성기에 넘길 질의를 만든다. 파라미터 값은 대개 이전 도구 출력에서 추출되므로 미리 예측하기 어렵다 — get_time()이 "2030-09-13"을 출력하면 에이전트는 다음 단계의 파라미터를 start_date="2030-09-07", end_date="2030-09-13", num_products=1처럼 추론한다. 정보가 부족하면("인기 제품의 평균 가격은?"에서 "몇 개의 인기 제품인지", "어느 기간인지"가 불명확) 모델이 사용자 요구를 추측해야 하고, 추측이 틀릴 수 있다. 행동 순서와 파라미터 모두 모델이 생성하므로 환각(존재하지 않는 함수 호출, 잘못된 파라미터로 유효한 함수 호출)이 발생할 수 있다. 계획 수립 능력을 높이는 방법은 더 나은 시스템 프롬프트(예시 추가), 도구·파라미터에 대한 더 자세한 설명, 함수를 더 단순하게 쪼개기, 더 강력한 모델 사용, 계획 생성을 위한 파인튜닝이다.

계획의 세부성. 계획은 분기별 계획처럼 큰 그림일 수도, 주별 계획처럼 세부적일 수도 있다 — 세부적인 계획은 생성은 어렵지만 실행이 쉽고, 큰 틀의 계획은 생성이 쉽지만 실행이 어렵다. 이 절충을 피하는 방법이 계층적 계획 수립(큰 그림을 먼저 세우고 각 부분을 더 자세히 채워 나가는 것)이다. 정확한 함수 이름을 쓰는 세부적인 계획은 도구 이름이 바뀌면(get_time()→get_current_time()) 프롬프트·예시·파인튜닝된 모델을 전부 갱신해야 하는 문제가 있다. 그래서 계획을 함수 이름 대신 "현재 날짜 가져오기 → 지난주 베스트셀러 조회 → 제품 정보 조회 → 쿼리 생성 → 응답 생성"처럼 자연어로 쓸 수도 있다. 자연어 계획은 도구 API 변화에 유연하고 환각도 적지만, 각 자연어 행동을 실행 가능한 명령으로 옮기는 번역기가 추가로 필요하다(다만 번역은 계획 수립보다 훨씬 간단해 가벼운 모델로도 할 수 있다).

제어 흐름. 지금까지의 예시는 모두 순차 실행(다음 행동이 이전 행동 완료 후 실행)이었다. 다른 제어 흐름은 다음과 같다.

• 병렬 실행 — 예: "100달러 미만 베스트셀러를 찾아줘"에서 상위 100개를 검색한 뒤 각 제품의 가격을 동시에 조회.
• If 조건문 — 예: 실적 보고서 내용에 따라 주식을 팔지 살지 분기.
• For 반복문 — 예: 특정 조건(소수 발견 등)이 충족될 때까지 반복.

전통적인 소프트웨어 공학은 제어 흐름 조건이 명확히 정의되지만, AI 기반 에이전트는 모델이 스스로 제어 흐름을 결정한다. 순차가 아닌 계획은 만들기도, 실행 가능한 명령으로 옮기기도 더 어렵다 — 에이전트 프레임워크를 고를 때 어떤 제어 흐름을 지원하는지(예: 10개 웹사이트를 동시에 검색할 수 있는지) 확인해야 한다.

성찰 및 오류 수정. 성찰은 필수는 아니지만 성공 가능성을 높인다. 질의 실현 가능성 검토, 계획 타당성 확인, 각 실행 단계 후 방향 점검, 전체 실행 후 완료 여부 확인 등 여러 단계에서 쓰인다. 성찰과 오류 수정은 밀접히 연결된 별개의 메커니즘으로, 성찰의 통찰이 수정할 오류를 찾는 데 도움이 된다. 성찰은 같은 에이전트가 자기 비평 프롬프트로 할 수도, 점수를 매기는 별도의 평가 모델로 할 수도 있다.

ReAct(Yao et al., 2022)는 추론과 행동을 교차하는 패턴으로 널리 쓰이게 됐다. 각 단계에서 에이전트는 생각을 설명하고(계획), 행동하고, 관찰 결과를 분석(성찰)하는 과정을 작업 완료까지 반복한다.

생각 1: ...
행동 1: ...
관찰 1: ...
...(성찰을 통해 작업 완료로 판단할 때까지 반복)...
생각 N: ...
행동 N: 완료 [질의에 대한 응답]

원문의 예시("애플 리모트 외에, 애플 리모트의 원래 제어 대상이었던 프로그램을 제어할 수 있는 다른 기기는?")는 ① '애플 리모트'를 검색해 원래 제어 대상을 확인 → ② 제어 대상이 '프론트 로우'임을 확인 → ③ '프론트 로우'를 못 찾아 '프론트 로우(소프트웨어)'로 재검색 → ④ 그 소프트웨어가 애플 리모트나 '키보드 기능 키'로 제어됨을 확인, 정답 도출의 흐름을 보여준다.

성찰은 멀티 에이전트로도 구현할 수 있다 — 한 에이전트가 계획·행동을 하고 다른 에이전트가 각 단계 또는 여러 단계 후 결과를 평가하는 식이다. Reflexion(Shinn et al., 2023)이 이 접근을 취한다 — 성찰을 평가자(결과를 평가)와 성찰 모듈(무엇이 잘못됐는지 되짚음) 두 모듈로 나눈다. 예를 들어 코드 생성에서 평가자가 테스트 케이스의 1/3이 실패했다고 판단하면, 에이전트는 "모든 숫자가 음수인 배열을 고려하지 않았다"고 성찰하고, 그 문제를 해결한 새 코드를 생성한다. 계획 생성 대비 성찰은 구현이 상대적으로 쉽고 성능 향상 폭이 크지만, 생각·관찰·행동 생성에 토큰이 많이 들어 지연 시간과 비용이 늘어나는 단점이 있다.

도구 선택. 완벽한 도구 조합을 고르는 방법은 없다 — 툴포머(Toolformer, Schick et al., 2023)는 5개, 카멜레온은 13개, 고릴라(Gorilla, Patil et al., 2023)는 1,645개 API 중에서 고르게 했다. 도구가 많을수록 능력은 커지지만 효율적으로 쓰기는 어려워지고(사람이 너무 많은 도구를 다 익히기 어려운 것과 같다), 도구 설명이 늘면 컨텍스트 한계도 초과할 수 있다. 결정에 도움이 되는 방법은 ① 여러 도구 조합으로 성능 비교, ② 도구를 하나씩 빼 보는 제거 연구(성능 저하 없이 뺄 수 있으면 제외), ③ 에이전트가 자주 실수하는 도구 파악(교체 검토), ④ 도구 호출 분포 시각화(가장 많이/적게 쓰이는 도구 파악)다. 카멜레온 연구는 작업마다 필요한 도구가 다르고(ScienceQA는 지식 검색에, TabMWP는 수학 문제 풀이에 더 의존), 모델마다 선호 도구도 다르다는 것(GPT-4가 챗GPT보다 다양한 도구를 선택)을 보였다. 카멜레온의 "도구 전환" 연구는 도구 X 사용 후 도구 Y를 호출할 확률을 추적해, 자주 함께 쓰이는 도구 쌍을 하나의 더 강력한 도구로 합칠 수 있다는 아이디어를 제시했다. 보이저(Voyager, Wang et al., 2023)는 에이전트가 습득한 새 스킬(코딩 프로그램 형태)을 스킬 라이브러리에 저장해 재사용하는 스킬 매니저를 제안했다.

5.4 에이전트 실패 유형과 평가

평가는 실패를 발견하는 과정이다. 작업이 복잡할수록 실패 가능성도 커지며, 에이전트는 3장(평가 방법론)·4장 §생성 능력 — 사실 일관성·§생성 능력 — 안전성에서 다룬 일반적인 AI 애플리케이션 실패 외에도 계획 수립·도구 실행·효율성과 관련된 고유한 실패를 겪는다.

계획 수립 실패. 가장 흔한 유형은 도구 사용 실패다.

• 유효하지 않은 도구 — 도구 목록에 없는 도구(예: bing_search)를 계획에 포함.
• 유효한 도구, 유효하지 않은 파라미터 — lbs_to_kg가 파라미터 하나만 받는데 두 개로 호출.
• 유효한 도구, 잘못된 파라미터 값 — lbs_to_kg(lbs=100)을 호출해야 하는데 120을 사용.

또 다른 유형은 목표 달성 실패(작업을 해결하지 못하거나 제약을 따르지 않음 — 예산 5,000달러 제약을 초과한 여행 계획)와 성찰 오류(실제로는 미완료인데 완료로 확신 — 50명을 30개 객실에 배정해야 하는데 40명만 배정하고 완료라고 보고)다. 시간도 중요하지만 간과되는 제약이다 — 마감이 지나서야 끝난 결과물은 쓸모가 없다.

계획 수립 실패를 평가하려면 (작업, 도구 목록) 쌍으로 데이터셋을 만들고, 각 작업에 대해 $K$개의 계획을 생성해 다음을 계산한다 — ① 유효한 계획의 비율, ② 유효한 계획 하나를 얻는 데 필요한 평균 생성 횟수, ③ 유효한 호출의 비율, ④ 유효하지 않은 도구 호출 빈도, ⑤ 유효한 도구가 잘못된 파라미터로 호출되는 빈도, ⑥ 유효한 도구가 잘못된 파라미터 값으로 호출되는 빈도. 어떤 작업 유형·도구에서 더 많이 실패하는지 패턴을 찾아, 더 나은 프롬프트·예시·파인튜닝으로 개선하거나 그래도 안 되면 도구 자체를 교체한다.

도구 실패. 올바른 도구를 썼지만 결과가 잘못된 경우다 — 이미지 캡션 생성기가 잘못된 설명을 내거나 SQL 생성기가 잘못된 쿼리를 만드는 경우, 큰 틀의 계획을 실행 명령으로 옮기는 번역 과정의 오류, 또는 필요한 도구 자체가 없는 경우(인터넷 접근이 안 되는데 실시간 주가가 필요한 경우)다. 도구마다 실패 양상이 다르므로 각 도구를 개별 테스트해야 하며, 모든 도구 호출과 결과를 출력해 검사·평가할 수 있게 해야 한다. 도구 부재 실패를 발견하려면 어떤 도구가 필요한지 알아야 하며, 해당 분야 전문가와 협업해 그들이 실제로 어떤 도구를 쓰는지 관찰하는 것도 도움이 된다.

효율성. 올바른 계획으로 작업을 완수해도 과정이 비효율적일 수 있다 — 평균 몇 단계가 필요한지, 평균 비용이 얼마인지, 어느 행동이 시간·비용을 많이 잡아먹는지를 확인한다. 이런 지표로 다른 에이전트나 사람과 비교할 수 있지만, AI와 사람의 작동 방식이 다르다는 점을 감안해야 한다 — 100개 웹 페이지를 순서대로 봐야 하는 사람에겐 부담이지만, 동시에 방문할 수 있는 AI 에이전트에겐 간단한 작업일 수 있다.

6. 메모리

메모리는 모델이 정보를 저장하고 활용하는 방식이다. RAG처럼 방대한 지식을 다루는 애플리케이션은 물론, 여러 단계를 거치는 에이전트에도 유용하다 — 지시·예시·컨텍스트·도구 목록·계획·도구 출력·성찰을 저장해야 하기 때문이다. AI 모델의 메모리는 세 가지로 나뉜다.

• 내부 지식 — 모델이 학습 데이터에서 얻어 담고 있는 지식. 모델이 다시 업데이트되기 전까지는 변하지 않으며 모든 질의에서 접근 가능하다.
• 단기 메모리 — 모델의 컨텍스트. 이전 대화 내용을 넣어 두면 다음 응답에 활용되지만, 작업(질의)이 끝나면 사라진다. 접근은 빠르지만 용량이 제한돼 현재 작업에 가장 중요한 정보를 담는 데 쓴다.
• 장기 메모리 — RAG처럼 모델이 검색으로 접근하는 외부 데이터 소스. 작업이 끝나도 유지되며, 모델 자체를 업데이트하지 않고도 수정·삭제할 수 있다.

사람의 기억도 비슷하게 나눌 수 있다 — 호흡법은 내부 지식(거의 안 잊는다), 방금 만난 사람 이름은 단기 메모리, 책·메모장 같은 외부 도구는 장기 메모리다. 어떤 정보를 어디에 둘지는 사용 빈도로 정한다 — 모든 작업에 필수적인 정보는 학습·파인튜닝으로 내부 지식화하고, 거의 안 쓰는 정보는 장기 메모리에, 지금 작업·대화에 바로 필요한 정보는 단기 메모리에 둔다.

메모리 시스템의 이점. ① 세션 내 정보 과부하 관리 — 컨텍스트 길이를 넘는 정보는 장기 메모리로 옮긴다. ② 세션 간 정보 유지 — 매번 자기소개를 다시 해야 하는 AI 코치는 쓸모가 없다. 이전 대화(예: 사용자가 『삼체』를 좋아했다는 것)를 기억하면 맞춤화된 추천이 가능하다. ③ 모델의 일관성 향상 — 이전 응답을 기억하면 같은 주관적 질문(농담 평점 등)에도 더 일관되게 답한다. ④ 데이터 구조 무결성 유지 — 텍스트 컨텍스트는 본질적으로 비정형이라, 표를 한 줄씩 넣어도 모델이 표로 이해한다는 보장이 없다. 구조화된 데이터를 담는 메모리 시스템(엑셀 시트, 큐 같은 자료구조)은 구조를 지켜 준다.

메모리 시스템은 보통 메모리 관리(무엇을 단기/장기에 저장할지)와 메모리 검색(장기 메모리에서 작업 관련 정보를 찾기 — RAG 검색과 유사)이라는 두 기능으로 구성된다. 장기 메모리는 저장 공간이 저렴하고 확장이 쉬워 삭제 전략이 덜 급하지만, 단기 메모리는 컨텍스트 길이 제한 때문에 무엇을 추가·삭제할지 전략이 필요하다. 컨텍스트의 일부(예: 30%)를 장기 메모리 검색 결과에 할당하면, 단기 메모리는 나머지(70%)만 쓸 수 있고 그 한계를 넘으면 넘치는 정보가 장기 메모리로 이동한다.

메모리 관리 전략. 가장 단순한 것은 선입선출(FIFO)이다 — 가장 먼저 들어온 정보가 가장 먼저 밀려난다. 오픈AI 같은 API 제공업체는 긴 대화의 초반부를 지우고, 랭체인 같은 프레임워크는 최근 N개 메시지·토큰만 유지하게 할 수 있다. 이 전략은 초기 메시지가 덜 중요하다고 가정하는데, 대화의 목적이 처음에 명시된 경우처럼 이 가정이 심각하게 틀릴 수 있다. 더 정교한 전략은 중복 축소다 — 요약을 활용하면 중복을 크게 줄일 수 있다. 배(Bae) 등(2022)의 연구는 요약에서 놓친 핵심 정보와 기존 메모리를 결합해, 각 문장을 새 메모리에 넣을지(하나만, 둘 다, 혹은 둘 다 제외) 판단하는 분류기를 개발했다. 리우(Liu) 등(2023)의 연구는 성찰 기반 접근을 썼다 — 각 행동 후 에이전트가 ① 새 정보에 대해 성찰하고, ② 그 정보를 메모리에 추가할지, 기존 메모리와 병합할지, 오래되거나 모순되는 다른 정보를 대체할지 결정하게 한다. 모순되는 정보 처리는 최신 정보를 우선하는 방식과 AI에게 판단시키는 방식이 갈리며, 활용 사례에 따라 다르다(모순이 혼란을 줄 수도, 다양한 관점을 보여 줄 수도 있다).

핵심 개념 정리

실무 체크리스트

• [ ] 지식 베이스가 모델 컨텍스트 한계(예: 20만 토큰) 안에 들어오는데도 RAG부터 도입하려 하지 않았는가?
• [ ] 검색기를 고를 때 "용어 기반 vs 임베딩 기반"만 보고 하이브리드·재순위화 조합을 검토하지 않지는 않았는가?
• [ ] 청크 크기·겹침을 실험 없이 임의로 고정하지 않았는가?
• [ ] 컨텍스트 정밀도만 보고 재현율(또는 최종 응답 품질)을 함께 확인했는가?
• [ ] 대화형 질의에서 질의 재작성 없이 모호한 후속 질문을 그대로 검색에 넘기지 않는가?
• [ ] 에이전트에게 줄 도구 목록을 "많을수록 좋다"는 가정으로 무한정 늘리지 않았는가?
• [ ] 계획을 검증 없이 바로 실행하게 두어, 무의미한 단계에 시간·비용을 낭비하지 않는가?
• [ ] 함수 호출의 파라미터 값을 사람이 검토할 경로 없이 자동 실행만 허용하지 않았는가?
• [ ] 도구에 쓰기 권한(송금·삭제 등)을 줄 때 위험도에 맞는 승인 절차를 두었는가?
• [ ] 에이전트 평가에서 계획 수립 실패·도구 실패·효율성을 따로 측정하고 있는가?

연습문제

1. 유형: 판단. 사내 문서가 5만 토큰 분량이고 매주 조금씩 바뀐다. RAG를 도입할지, 프롬프트에 전부 넣을지 판단 기준을 두 가지 이상 들어 설명하라.
2. 유형: 설계. 오류 코드("ERR-4042" 같은)를 자주 포함하는 기술 지원 문서 데이터베이스에서 검색 시스템을 설계한다면, 희소 검색과 밀집 검색 중 어느 쪽을 우선하고 왜 그런지, 그리고 부족한 부분을 어떻게 보완할지 설명하라.
3. 유형: 실무 시나리오. 고객 지원 챗봇 에이전트가 환불 처리 도구(쓰기 행동)에 접근할 수 있다. 이 도구를 안전하게 배치하기 위한 계획 검증·승인 절차를 단계별로 제안하라.
4. 유형: 분석. 어떤 에이전트가 "50개 주문을 처리했다"고 보고했지만 실제로는 38개만 처리됐다. 이 실패를 §5.4의 세 실패 유형(계획 수립 실패·도구 실패·비효율) 중 어디로 분류할지 근거와 함께 설명하고, 이런 실패를 미리 잡아낼 평가 방법을 제안하라.
5. 유형: 비교. FIFO 메모리 관리와 요약 기반 메모리 관리 중 "대화 시작에 목적이 명시된 긴 상담 세션"에 어느 쪽이 더 적합한지 근거를 들어 설명하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-12) — 이 장의 개념(검색·에이전트·메모리)은 그대로 유효하다. 책 출간 이후 특히 두 가지가 더 표준화·정교화됐다.

• 도구 호출의 프로토콜 표준화 — Model Context Protocol(MCP). 이 장 §5.2가 "함수 호출이 앞으로 표준으로 자리잡을 것"이라 전망한 방향이 구체적인 개방 표준으로 이어졌다. 앤트로픽이 2024년 11월에 공개한 MCP는 AI 애플리케이션이 도구·데이터 소스에 연결하는 방식을 통일한 개방 프로토콜이며, 이후 OpenAI·구글 딥마인드 등 주요 모델 제공업체가 지원을 발표했고 2025년 12월 리눅스 재단 산하로 이관됐다. 도구 목록·파라미터·문서를 정의하는 §5.2의 "함수 호출" 절차 자체는 이 장에서 설명한 그대로다.
• RAG의 에이전트화 — Agentic RAG. 이 장의 RAG는 "검색 → 생성"의 고정된 두 단계 파이프라인을 전제한다. 이후 업계에서는 검색기를 에이전트의 계획·추론 루프 안에 넣어, 질의를 반복적으로 다듬고 여러 번 검색하며 결과를 스스로 점검하는 "에이전틱 RAG(Agentic RAG)" 구성이 널리 논의되고 있다 — §5.1이 이미 언급한 "RAG는 검색기가 도구인 특별한 형태의 에이전트"라는 관점의 실제 구현이다. 이 장 §1~4의 구성 요소(청킹·재순위화·질의 재작성)는 에이전틱 RAG에서도 그대로 재사용된다.

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-12)

• RAG 원논문 — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020)
• ReAct 논문 — ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)
• Reflexion 논문 — Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., 2023)
• 컨텍스트 검색 공식 설명 — Introducing Contextual Retrieval (Anthropic, 2024)
• 도구 연결 표준 공식 소개 — Model Context Protocol 소개
• 밀집 벡터 검색 라이브러리 — FAISS (facebookresearch/faiss)
• HNSW 근사 최근접 이웃 라이브러리 — Hnswlib (nmslib/hnswlib)

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 판단 기준 예시 — ① 지식 베이스 크기가 컨텍스트 한계(예: 20만 토큰) 안에 들어오는가: 들어온다면 RAG 없이 프롬프트에 전부 넣는 편이 구조가 단순하다(§1의 앤트로픽 조언). ② 변경 빈도와 최신성 요구: 매주 바뀌는 문서를 매번 전체 프롬프트로 새로 넣으면 프롬프트 캐싱 이득이 줄고 비용이 커질 수 있으므로, 변경된 부분만 재색인하는 RAG가 유지보수 면에서 유리할 수 있다. 결국 "한 번에 다 들어가는가"와 "얼마나 자주, 어느 범위가 바뀌는가"를 함께 봐야 한다.
2. (문제 2 정답) 오류 코드처럼 정확한 문자열 일치가 중요한 도메인에서는 희소 검색(BM25 등)이 유리하다 — 밀집 검색은 임베딩 과정에서 ERR-4042 같은 특정 문자열이 희석돼 놓치기 쉽다(§2 "용어 기반 vs 임베딩 기반" 논의). 다만 사용자가 오류 코드를 정확히 모르고 증상만 서술하는 질의도 많으므로, 밀집 검색을 함께 써서 의미 기반으로 보완하는 하이브리드 검색(순차 결합 또는 RRF 앙상블, §2)이 적절하다.
3. (문제 3 정답) 예시 절차 — ① 환불 요청 질의가 들어오면 의도 분류기로 "환불" 의도인지 먼저 확인한다(§5.3). ② 에이전트가 환불 금액·주문 정보를 채운 계획을 생성한다. ③ 계획을 휴리스틱(금액이 주문 금액을 넘지 않는지 등)과 AI 평가자로 검증한다. ④ 일정 금액 이상이거나 정책에서 벗어나는 계획은 사람의 명시적 승인을 요구하도록 자동화 수준을 낮춘다(§5.3 "계획과 실행의 분리"). ⑤ 실행 후 환불이 실제로 처리됐는지 성찰 단계에서 재확인한다(성찰 오류 방지, §5.4).
4. (문제 4 정답) 이는 계획 수립 실패 중 성찰 오류에 가깝다 — 에이전트가 실제로는 작업을 완료하지 못했는데 완료했다고 확신한 경우이기 때문이다(§5.4, "50명을 30개 객실에 배정" 사례와 같은 유형). 미리 잡아내려면 실행 결과를 원래 목표(처리해야 할 총 건수)와 기계적으로 대조하는 검증 단계를 성찰과는 별도로 두어, "몇 건을 처리했다"는 자연어 보고를 실제 처리된 레코드 수와 항상 교차 확인해야 한다.
5. (문제 5 정답) 대화 시작에 목적이 명시된 긴 상담 세션에는 요약·성찰 기반 메모리 관리가 더 적합하다. FIFO는 "초기 메시지가 덜 중요하다"고 가정하는데(§6), 이 시나리오는 정확히 그 가정이 깨지는 경우다 — 첫 메시지(상담 목적)가 대화 내내 가장 중요한 정보일 수 있다. 요약 기반 접근은 핵심 개체·목적을 요약에 남겨 초반 정보가 밀려나지 않게 한다.